3 research outputs found
DSTC: DNS-based Strict TLS Configurations
Most TLS clients such as modern web browsers enforce coarse-grained TLS
security configurations. They support legacy versions of the protocol that have
known design weaknesses, and weak ciphersuites that provide fewer security
guarantees (e.g. non Forward-Secrecy), mainly to provide backward
compatibility. This opens doors to downgrade attacks, as is the case of the
POODLE attack [18], which exploits the client's silent fallback to downgrade
the protocol version to exploit the legacy version's flaws. To achieve a better
balance between security and backward compatibility, we propose a DNS-based
mechanism that enables TLS servers to advertise their support for the latest
version of the protocol and strong ciphersuites (that provide Forward-Secrecy
and Authenticated-Encryption simultaneously). This enables clients to consider
prior knowledge about the servers' TLS configurations to enforce a fine-grained
TLS configurations policy. That is, the client enforces strict TLS
configurations for connections going to the advertising servers, while
enforcing default configurations for the rest of the connections. We implement
and evaluate the proposed mechanism and show that it is feasible, and incurs
minimal overhead. Furthermore, we conduct a TLS scan for the top 10,000 most
visited websites globally, and show that most of the websites can benefit from
our mechanism
Towards Forward Secure Internet Traffic
Forward Secrecy (FS) is a security property in key-exchange algorithms which
guarantees that a compromise in the secrecy of a long-term private-key does not
compromise the secrecy of past session keys. With a growing awareness of
long-term mass surveillance programs by governments and others, FS has become
widely regarded as a highly desirable property. This is particularly true in
the TLS protocol, which is used to secure Internet communication. In this
paper, we investigate FS in pre-TLS 1.3 protocols, which do not mandate FS, but
still widely used today. We conduct an empirical analysis of over 10 million
TLS servers from three different datasets using a novel heuristic approach.
Using a modern TLS client handshake algorithms, our results show 5.37% of top
domains, 7.51% of random domains, and 26.16% of random IPs do not select FS
key-exchange algorithms. Surprisingly, 39.20% of the top domains, 24.40% of the
random domains, and 14.46% of the random IPs that do not select FS, do support
FS. In light of this analysis, we discuss possible paths toward forward secure
Internet traffic. As an improvement of the current state, we propose a new
client-side mechanism that we call "Best Effort Forward Secrecy" (BEFS), and an
extension of it that we call "Best Effort Forward Secrecy and Authenticated
Encryption" (BESAFE), which aims to guide (force) misconfigured servers to FS
using a best effort approach. Finally, within our analysis, we introduce a
novel adversarial model that we call "discriminatory" adversary, which is
applicable to the TLS protocol
DSTC: DNS-based strict TLS configurations
Most TLS clients such as modern web browsers enforce coarse-grained TLS security configurations. They support legacy versions of the protocol that have known design weaknesses, and weak ciphersuites that provide fewer security guarantees (e.g. non Forward-Secrecy), mainly to provide backward compatibility. This opens doors to downgrade attacks, as is the case of the POODLE attack [18], which exploits the client’s silent fallback to downgrade the protocol version to exploit the legacy version’s flaws. To achieve a better balance between security and backward compatibility, we propose a DNS-based mechanism that enables TLS servers to advertise their support for the latest version of the protocol and strong ciphersuites (that provide Forward-Secrecy and Authenticated-Encryption simultaneously). This enables clients to consider prior knowledge about the servers’ TLS configurations to enforce a fine-grained TLS configurations policy. That is, the client enforces strict TLS configurations for connections going to the advertising servers, while enforcing default configurations for the rest of the connections. We implement and evaluate the proposed mechanism and show that it is feasible, and incurs minimal overhead. Furthermore, we conduct a TLS scan for the top 10,000 most visited websites globally, and show that most of the websites can benefit from our mechanism